Currently, techniques for establishing communication between two communicating entities exist and are deployed within communication networks, for example between two user terminals, between communicating applications deployed on equipment of a network or between a user terminal and an application server.
However, direct communications between different communicating entities over the Internet network are difficult to implement due to the complexity of the network architectures deployed and the many private or local networks through which the communicating entities access the Internet network. This difficulty results in particular from the use of protocols constituting hindrances to the implementation of point-to-point dynamic connections. For example, NAT gateways converting local addresses of a local network into public addresses on the Internet network, and vice versa, do not allow efficient implementation of the establishment of such point-to-point connections. Indeed, the consequence of implementing of a NAT gateway to access other networks is that it masks the addresses of the equipment of a local network and in particular of clients and services accessible from the local network.
To mitigate these difficulties, Interactive Connectivity Establishment, abbreviated to ICE, is known, which enables communication routes to be defined between point-to-point communicating entities, taking into account the architecture of NAT gateways.
This technique is used, in particular, for Voice over IP protocols, abbreviated as VoIP, transmission of video streams, or instant message transmissions. The ICE technique is often associated with the STUN (RFC5389) and TURN (RFC 5766) protocols. The STUN and TURN protocols refer respectively to Session Traversal Utilities for NAT and Traversal Using Relays around NAT. These are protocols which allow the implementation of NAT techniques when a discovery of addresses is required, or when a relaying third party is required to overcome the difficulties, for example, of implementation of a Firewall with a NAT technique.
One problem arises from the fact that a point-to-point connection established between two services or two clients of two devices in different networks connected to the Internet network usually implies in the case of certain media an indication of a communication port which depends on the type of media. Although a NAT gateway enables correspondences of addresses of a local/private network to a public network to be made, and vice versa. Indeed, a NAT gateway does not necessarily manage the reassignments of the ports when the addresses of the headers of the transmitted messages change, since these messages are indicated in the bodies of the exchanged messages. This is the case, in particular, when a NAT gateway is used with the SIP protocol, where this acronym stands for Session Initialisation Protocol.
A STUN server enables data relating to the various types of public and local addresses and the port numbers to be exchanged between two communicating entities in order that the latter can communicate through NAT gateways and with different application resources.
Today, ICE techniques associated with the STUN and TURN protocols have mechanisms to reconstruct application sessions when a device is disconnected or when switching from one network to another. One advantage of these mechanisms is that they allow a certain mobility of a terminal, whilst ensuring independence relative to the network architecture. In particular, these mechanisms are independent of the network architecture, in particular the architecture of NAT gateways or firewalls, in order to make data communications immune from the path taken by the data packets.
However, when a terminal which is communicating with an application server changes access networks to an Internet network, or when it is disconnected and reconnected to a same local network, a disadvantage of the above techniques is that the application session must be reconfigured between the terminal and the application server. Even if the data transmission channels are re-established, it is nonetheless the case that this is particularly problematic when switching from a first access network to a second access network, in particular when a user is mobile and wishes its application session to be maintained.
It will be understood that since reconfiguration of an application session between two communicating entities generally requires initialisation and preliminary data exchanges, this implies that latency times are made longer and that the offered services are discontinuous. As an example, the VoIP protocol requires a reconfiguration of the application session as rapidly as possible, bearing in mind the real-time constraints. Consequently, the mechanisms for reconstructing application sessions, although useful, appear insufficient to guarantee quality of service for a given user. One choice can be not to switch networks for as long as an application session is established, meaning that consideration of the new access network is disregarded.